Hey @mhenrixon, thanks for this! I haven't looked at it yet, but there's a previous PR for batch support: #142 and a discussion there. It's work in progress as well, but maybe the discussion there is relevant for this, too.

Hey @mhenrixon, thanks for this! I haven't looked at it yet, but there's a previous PR for batch support: #142 and a discussion there. It's work in progress as well, but maybe the discussion there is relevant for this, too.

Hey @rosa, so I had a look at the other PR!

Admittedly, I am biased, but I feel that my suggestion is more in line with the code I already saw in solid_queue. I don't care either way as long as the functionality ends up in a release in the not so distant future, though.

Would @jpcamara be open to share notes and get the feature across the finish line? I am more than happy to support you in finishing up the work in your branch.

@mhenrixon would be good to change the API to support batch enqueue using a block also so that:

SolidQueue::Batch.enqueue(metadata: { source: "test", priority: "high", user_id: 123 }) do
  SomeJob.perform_later('args')
  SomeJob.perform_later('args')
end

Which would support a use case we have where we have an around_action on certain controller methods that we like to batch all jobs performed in that action and provide a background job progress indicator. This wouldn't be possible if we have to explicitly list every job.

Job enqueue using a block is possible in #142

@mhenrixon would be good to change the API to support batch enqueue using a block also so that:

I'll continue the work this weekend. Has been super busy developing a Hotwire native app at work.

Thanks for letting me know about this.

I have some free time this coming week to put together some notes and figure out next steps.

I think neither of our PRs fully matches the solid queue model - the solid queue model has core tables and then execution models. Both of our PRs kind of dump everything into one hot path table. Maybe that's ok, I'm not sure yet.

I want to re-evaluate my approach and line it up better with the overall architecture of SQ. I'd be happy to try to work together on this

I have some free time this coming week to put together some notes and figure out next steps.

I think neither of our PRs fully matches the solid queue model - the solid queue model has core tables and then execution models. Both of our PRs kind of dump everything into one hot path table. Maybe that's ok, I'm not sure yet.

I want to re-evaluate my approach and line it up better with the overall architecture of SQ. I'd be happy to try to work together on this

Gonna dig into this PR as well and your approach, I've only reviewed it a bit so far

Gonna dig into this PR as well and your approach, I've only reviewed it a bit so far

Let me know if you want to team up on this. It is a much-needed feature.